Usar las palabras claves “es un” y “tiene un”
para encontrar la relación correcta
Herencia vs Agregación
Herencia y agregación a menudo se confunden
herencia representa una relación “es-un” o “tipo-de”
Agregación representa una relación “tiene-un”
Ejemplos:
Vendedor es un empleado;
Una orden tiene un Ítem
(Gp:) VehiculoMotor
(Gp:) Tractomula
(Gp:) Carro
(Gp:) Bus
(Gp:) UtilidadVehiculo
Herencia múltiple
En sistemas orientados a objetos a una clase se le permite heredar de más de una superclase
Esta clase de herencia se conoce como herencia múltiple
Ejemplo, UtilidadVehiculo hereda de las clases Tractomula y Carro
Problemas con herencia múltiple
Hay varios problemas con la herencia múltiple, entre otros:
Las subclases pueden heredar el mismo atributo de dos superclases diferentes
Las subclases pueden heredar la misma operación de dos superclases diferentes
La mayoría de los lenguajes orientados a objetos no soportan bien la herencia múltiple
PowerBuilder y Java manejan herencia simple
Trabajo adicional: Delegar ciertos atributos u operaciones en clases asociadas, usar agregación, o usar interfases en Java (se ven más adelante)
Interfase
Una interfase es un conjunto de operaciones usadas para especificar el comportamiento externo de una clase, objeto u otra entidad
En el caso de una clase u objeto, la interfase incluye la firma de las operaciones
La interfase es un concepto UML que también está en Java
No suportado en PowerBuilder
Se puede ver como un “contrato” para un conjunto de clases
Uso de interfases
Una interfase es similar a una clase abstracta, tiene atributos y operaciones como una clase, pero las operaciones son virtuales, no hay implementación de las operaciones
Para crear una interfase:
En la paleta, dar clic en la herramienta “Interface”
o
Seleccionar “Mode Interfaces” del menú principal para definir interfase
(continúa …)
Uso de interfases
Para vincular una clase a una interfase, asociar la interfase con la clase que “realiza” la interfase
Para establecer este vínculo, en la paleta dar clic en “Realization Drawing”, y dibujar la realización de la clase a la interfase
Propiedades de “Interface”
Name
Code
Comment
Stereotype
Visibility
Generate
Inner to
Propiedades de “Realization”
Name
Code
Comment
Interface
clase
Stereotype
Implementación de interfases
Las interfases son como entidades de clases que tienen operaciones (generalmente abstractas) y atributos
“To Be Implemented” es una facilidad que muestra qué operaciones de la interfase que su clase implementa se tienen que implementar
Al hacer clic en “Implement”, copia la firma de la operación a su clase para implementación
Uso de interfases
Evita herencia múltiple
Las interfases ayudan a evitar la herencia múltiple teniendo una clase que soporta múltiples interfases
Forza polimorfismo
Las interfases ayudan a usar polimorfismo forzando a las clases a soportar todos los atributos y operaciones de una interfases
Asegura un método consistente de nombre y llamado a través de múltiples clases
UML y Java soportan “final clases”
Clases que no se pueden heredar
Esto ayuda a asegurar que las clases no van a ser mal utilizadas por otros desarrolladores
Ejemplos:
Clases para seguridad
Clases con formas de trabajo
Final
Paquete (package)
Paquete es un mecanismo de propósito general para organizar elementos en grupos
Típicamente un modelo orientado a objetos se organiza en paquetes
Se puede pensar que un modelo completo es un paquete de alto nivel que contiene cualquier otro paquete dentro de él
Se usan paquetes para focalizar la funcionalidad en el sistema
Cada paquete tienen al menos un diagrama
Puede tener más de un diagrama
Paquetes en PowerDesigner
<>
Mi sistema
Paquetes
El concepto de paquetes en PowerDesigner corresponde al concepto de paquetes de Java, es decir, un conjunto de grupos de clases que ejecutan funciones relacionadas
Ejemplos:
El paquete AWT, parte del API, incluye clases para crear un sistema gráfico de ventanas
El paquete IO, usado por el sistema de E/S, streams, persistencia, y archivos
Se pueden usar paquetes para referirse a agrupamientos tanto físicos como lógicos de los elementos de un modelo
Se usan para particionar o para desarrollar
Paquetes
El uso de paquetes ayuda a garantizar la jerarquía del sistema
Un paquete puede contener otros paquetes
Se pueden anidar paquetes para formar una jerarquía
Esta capacidad de anidamiento ayuda a agrupar las clases, tal como una jerarquía de directorios puede ayudar a organizar los archivos
Cuando se genera código Java, un paquete se genera como un directorio en el sistema de archivos de destino
Jerarquía de paquetes
En PowerDesigner, los paquetes se muestran en el navegador como niveles separados
Propiedades de los paquetes
Name
Code
Comment
Stereotype
Namespace
Default diagram
Estereotipos de paquetes
Estereotipos comunes de paquetes:
Facade
Framework
Metamodel
Model
Stub
Subsystem
System
SystemModel
TopLevel
Espacio de nombres
Un espacio de nombres define el alcance en el cual un nombre y el código de un objeto de cualquier tipo dado debe ser único
Entonces, el nombre de un objeto de un modelo se puede forzar a que sea único a nivel de un modelo, paquete o subpaquete
En UML y Java,por default, los nombres de las clases deben ser únicos a nivel de paquete
Java resuelve esto en el momento de ejecución utilizando la variable CLASSPATH
PowerBuilder resuelve esto en el momento de ejecución utilizando la lista de la librería
En un modelo orientado a objetos, el paquete es el valor por omisión para el espacio de nombres
Dependencia de paquetes
Un paquete es un concepto de desarrollo de software
Uno de los objetivos principales es minimizar la dependencia de paquetes
Ejemplo: Mi Paquete1 depende de Mi Paquete2, significa que uno o más elementos en el Paquete1 dependen de uno o más elementos en el Paquete2
Un cambio en un Paquete puede requerir de uno o más cambios en los elementos fuente del paquete dependiente
Relaciones de Paquetes
El único tipo de relación entre paquetes es la relación de dependencia
Si una clase en un paquete se refiere a una clase en otro paquete, se debe añadir una dependencia de relación a nivel de paquete
Evaluar clases y diagramas de clases para determinar relaciones entre paquetes
Dependencia de paquetes – Implicaciones
Ejemplo:
Siempre que se haga un cambio en “Service package”, “Client package” se debe volver a compilar y a probar
“Client package” no se puede reutilizar independientemente porque él depende de “Service package”
Interfase pública de un paquete
Cada clase en un paquete tiene un parámetro de visibilidad que se puede colocar en público, paquete, privado, o protegido
Solamente las clases públicas pueden ser utilizadas por clases en otros paquetes
Evaluar las partes públicas y privadas de un paquete
No todas las clases en un paquete deben hacer parte de la interfase pública del paquete
Evitar dependencias circulares
Una jerarquía de paquetes debe ser asimétrica
Tratar de evitar el siguiente escenario: El paquete A usa el Paquete B y el Paquete B usa el Paquete A
La dependencia circular entre los paquetes A y B es un indicativo para tratarlos como un único paquete
Evitar este tipo de círculo entre más de dos paquetes
Ejemplo: El paquete A usa el Paquete B, el Paquete B usa el Paquete C y el Paquete C usa el Paquete A
Estas dependencias circulares se deben romper reestructurando uno o más paquetes
Reestructuración de paquetes
Se debe pensar en la reestructuración de paquetes en un modelo si:
Hay un acoplamiento fuerte entre los paquetes, lo que significa que los paquetes se deben combinar
Hay dependencia en doble vía entre los paquetes, lo que significa que las clases se deben reorganizar
La interfase de un paquete debe encapsular su implementación en una interfase pública tal como lo hace una clase
Evaluar las consideraciones de reutilización
Para que sea reutilizable, un paquete debe tener pocas dependencias
Ejemplo: mirar los paquetes de Java
Reglas del negocio
Una “Regla del negocio” es algo que se debe cumplir
Ejemplo de Reglas de negocio:
Las leyes gubernamentales
Requerimientos del cliente
Guía de cumplimiento interno
Las reglas del negocio a menudo comienzan como simples observaciones
Ejemplo: “Los clientes llaman por los número gratis para colocar sus pedidos”
Durante el diseño hay que desarrollar esas observaciones en expresiones más detalladas
Reglas del negocio
Ejemplos:
Lo que puede comprar un cliente de acuerdo a la línea de crédito
Información que debe proporcionar un cliente cuando hace un pedido
Las reglas del negocio complementan los modelos gráficos con información que no se puede representar fácilmente en forma gráfica
Ejemplos:
La regla “un empleado pertenece a uno y solo un departamento”, indica el tipo de relación entre un empleado y un departamento
Fórmulas algebraicas, restricciones, reglas de validación
Reglas del negocio – Propiedades
Name
Code
Comment
Type
Expression
Notes
Tipos de reglas del negocio
Restricciones – Condición a chequear sobre un valor
Definición – características o propiedades de un objeto en el sistema
Hechos – cosas ciertas o existentes en el sistema
Fórmulas – calculos empleados en el sistema
Requerimientos – especificación funcional en el sistema
Validación – restricción sobre un valor en el sistema
Domains
Classes
Interfaces
Attributes
Identifiers
Operations
Associations
Generalizations
Realizations
Dependencies
Use Cases
Actors
Objects
Messages
Reglas del negocio y modelado con objetos
Las reglas del negocio se pueden ligar a los siguientes objetos en un modelo orientado a objetos:
Dominio
Un dominio es el conjunto de valores válidos para un data ítem
En el caso de PowerDesigner, existen con el mismo significado en los tres modelo OOM, CDM y PDM
Los dominios se usan para forzar manejo consistente de datos en el sistema
Name
Code
Comment
Stereotype
Data type
Multiplicity
Standard checks
Additional checks
Rules
Dependencies
Dominio – Propiedades
Selección del tipo de datos
Seleccionar un clasificador
Una Clase o Interfase se puede usar como un tipo de dato
Usar la herramienta seleccionadora de clasificación para mostrar la lista
Propiedades de dominio – “Detail”
“Detail” sirve para mejorar la generación de código y tipos de datos en la generación de un CDM o PDM
Aquí los tipos de datos son internos de PowerDesigner
“Persistent” se ve más adelante
Dominios y divergencia
Si se forza “non-divergence”, un data ítem no puede tener un tipo de dato diferente del dominio
Se dice que se tiene un modelo “honest”
Ventana Model Options – Se puede forzar “non-divergence” entre un dominio y los data ítem que usan el dominio
Diagrama de Secuencia
En un sistema en funcionamiento los objetos interactúan entre sí
Las interacciones suceden a través del tiempo
Los objetos interactúan mandándose mensajes
Un mensaje hace que un objeto haga algo
El diagrama de clases representa la parte estática
El diagrama de secuencia muestra la parte dinámica de las interacciones
Representa un trabajo producto del proceso de diseño
Modelamiento de interacciones
Durante el análisis se puede hacer el modelamiento de las interacciones, si es necesario, pero típicamente es una técnica de modelamiento durante el diseño y la construcción
Se pasa del “qué” al “cómo”
Objetivos del modelado de interacciones:
Ver el comportamiento entre objetos
Mostrar de forma detallada las interacciones que ocurren entre objetos a través del tiempo
Detallar la distribución de operaciones entre clases
Diagrama de Secuencia
Con el diagrama de clases y analizando los casos de uso se puede conceptualizar las partes del sistema pero queda pendiente la interacción entre ellas
Esta información hace más sencillo el trabajo de los programadores
Les da una visión de cómo codificar las clases y ponerlas a trabajar juntas
Un diagrama de secuencia se puede usar para refinar la descripción de un caso de uso y ayuda a encontrar objetos adicionales
Típicamente se tiene un diagrama de secuencia para el flujo principal de eventos y uno por cada sub-flujo independiente del caso de uso
Diagramas de Secuenciay sistemas multicapa
Los diagramas de secuencia son indispensables para el desarrollo de sistemas multicapa (multi-tier systems)
Generalmente la interacción y coordinación entre objetos de diferentes capas es compleja
Ejemplo: Interacción que ocurre entre objetos lógicos del negocio en una capa, los objetos de base de datos en otra capa y los múltiples tipos de objetos de la interfase (browser, PDA o Windows)
Los diagramas de secuencia pueden gráficamente representar esas interacciones haciendo que sea más fácil entenderlas
Componentes de un diagrama de secuencia
Objetos
Representados como rectángulos en la parte superior del diagrama
Actores se pueden representar de forma opcional
Mensajes
Representados como flechas
Tiempo
Representado en la dirección vertical
La línea de vida de un objeto es la línea punteada que baja desde el objeto
La duración de la ejecución de una operación (activación) se puede representar como un rectángulo a lo largo de la línea de vida del objeto (opcional)
 Página anterior | Volver al principio del trabajo | Página siguiente  |